Amazon IVS Low-Latency Streamingで新たにサポートされたMultitrack Videoについて確認してみた
2025.01.03はじめに
清水です。Amazon IVS Low-Latency Streamingで新たにMultitrack Videoという機能をサポートしました。AWS re:Invent 2024の少し前、2024/11/14にWhat's New at AWSへポストされていたアップデートです。
Multitrack Video機能を使用すると、ABR用の各レンディションの映像をAmazon IVSによるトランスコードではなく、自身のデバイスから直接送信するようになり、Standard Channelの入力コストの削減につながるということです。
本エントリでは、このMultitrack Videoについて、User Guideなどからその概要やメリット、注意事項などを確認してみます。またマネジメントコンソールからMultitrack Videoを有効にしたChannelの作成までの流れについても確認してみました。
なお、上記What's New at AWSのポストでは、Amazon IVSのLow-Latency Streaming向けの機能なのかReal-Time Streaming向けの機能なのか、どちらかについては直接触れられていません。しかしドキュメントなどの内容から、Amazon IVS Low-Latency Streaming向けの機能と判断しています。
IVSのMultitrack Videoについてドキュメントから確認してみた
Amazon IVS Low-Latency StreamingのMultitrack Video機能、What's New at AWSのポストによると、ABR用のトランスコーディングをIVSではなく自分のデバイスを使用して行う、ということです。これが実際にどんな動作なるのか、Amazon IVS Low-Latency Streaming User Guideに通常の（IVSでABR用のトンラスコードを行う）場合との比較がありますので、まずはこちらを確認してMultitrack Video機能の概要を掴んでみましょう。
まずはMultitrack Video機能を使わない場合（これを Single-track Video と称しています）のIVSの動作です。
StreamerはOBS StudioなどのBroadcast Softwareを使って映像をIVS Channelに打ち上げます。この際、プロトコルにはRTMPが使用されますね。IVS Standard Channelでは受け取った映像をAdaptive Bitrate (ABR)用にトランスコードします。例として、Broadcast Software側から1080p60の打ち上げたとします。この際、IVS Standard Channelでは、1080p60からトランスコードされた720p60、480p30、360p30、160p30の各レンディションを含めたABRラダーで視聴者に映像の配信を行います。（入力解像度に対するABRラダーについては、User GuideのAmazon IVS Streaming Configurationにまとめられています。）
このABRラダーを準備するまでのトランスコード処理が、今回のアップデートである Multitrack Video 機能を使うと以下のようになります。
StreamerはMultitrack VideoをサポートしたBroadcast Softwareを使用します。（OBS StudioもMultitrack Videoをサポートしていますが、使用するためにはいくつか要件があるので注意しましょう。詳細については後述します。）Broadcast SoftwareではABRラダー用に複数解像度の映像をエンコードし、IVS Channelにまとめて打ち上げます。最高解像度である1080p60の解像度に加えて、720p60、480p30、360p30、160p30の各レンディションをあらかじめ Broadcast Software側でエンコード します。IVS Channelに打ち上げる際のプロトコルにはEnhanced RTMPが使われます。IVS Channel側では受け取った複数解像度の映像を、トランスコードはせずトランスマックス（コンテナ形式の変換、再パッケージ化）のみ行い、配信に使用します。
つまり、Multitrack Videoを有効にするとABR用の各レンディション映像の生成がサーバ側（IVS Standard Channel側）ではなく、映像を打ち上げる前のBroadcast Softwareで行われるわけですね。この変換は一般的に、Broadcast Softwareが稼働するコンピュータ上のGPUによって行われ、サーバ側で変換するよりも高い視聴品質を実現できるとのことです。また、サーバ側でデコード、スケーリング、再エンコードといった処理が省かれるため、レイテンシを低くすることにもつながるそうです。
Multitrack Video使用時のコストメリットについても確認してみた
続いては、IVS Low-Latency StreamingでMultitrack Video機能を有効化した際のコスト削減についても確認してみましょう。What's New at AWSのポストによると、Standard Channelでライブビデオ入力のコストを最大75%削減できるとのことです。
実際に、Amazon Interactive Video Service PricingのページでMultitrack Video機能を有効にした場合と、通常のStandard Channelとの比較をしてみましょう。Low-Latency StreamingのLive Video Input Costsの項目を確認します。
料金表にある通り、通常のStandard Channel（Multitrack Videoを有効にしていない状態）では、Live Video Input Costとして1時間あたり $2.00 が発生します。対して、Standard ChannelでMultitrack Videoを有効にした場合のLive Video Input Costは $0.50 です。1/4の価格で、通常のStandard Channelに比べて75%のコスト削減になっていますね。
Multitrack Videoを利用した際に料金が安価になる理由についても記載があります。Broadcast Software側（Streamerのデバイス）からABR用の各レンディションを送信することで、Amazon IVS側では各レンディションの作成が不要となります。トランスコード処理が不要となりコンピュータリソースの使用が減るため、料金も安価になる、ということですね。
なおAdvanced Channel Type（Advanced HD, Advanced SD）についても、コスト最適化を目的とした機能でした。（[UPDATE] Amazon IVSで品質とコストのバランスが最適化されたAdvanced Channel Typeが利用可能になりました！ | DevelopersIO）ただしAdvanced Channel Typeでは入力映像の品質よりも配信映像の品質を抑えることでコスト削減を実現しています。Multitrack Video機能を使えば、配信映像の品質を抑えることなくライブビデオ入力コストの削減が可能となります。
Multitrack Video利用時の注意事項
通常のStandard Channelと比べてライブビデオ入力のコストが75%削減され、より高い視聴品質を実現でき、またレイテンシが低くなるというMultitrack Video機能、とても便利そうですよね。ただし、使用するにあたってはいくつか注意事項があります。本章ではこのMultitrack Video利用時の注意事項について確認していきます。
Broadcast Softwareの要件について
まずはMultitrack Video利用時のBroadcast Softwareの要件について確認します。What's New at AWSのポストには、Multitrack VideoがOBS Stuidoでサポートされている旨の記載があります。しかし、どんな環境のOBS Studioでも利用できるかというとそうではなく、OBS Studioでも利用に際しいくつか条件があるようです。
Amazon IVS Low-Latency Streaming User GuideのAmazon IVS Multitrack Video: Setup Guide、「Broadcaster System and Environmental Requirements」の項目を確認してみましょう。推奨環境として以下の表ようにまとめられています。
Multitrack Video機能を有効にした際にBroadcast Software側で行われる、ABR用の各レンディション映像の生成は、一般的にGPU上で処理が行われるとのことでした。そのためか、GPUを搭載していることを要件としているようです。具体的にはNVIDIA GeForce 900 シリーズ以降、もしくはAMD Radeon RX 6000/7000 シリーズ以降のGPUが推奨されていますね。
またOBS Studioについてもv30.2以降が推奨されています。このOBS Studio 30.2については、2024/07/12にリリースれた現時点（2025/01/02）の最新版です。こちらのリリースノートについても確認してみましょう。
Multitrack Video StreamingのサポートがNew Featuresの冒頭に記載されていますね。またGPUの要件（NVIDIA GTX 900、GTX 10、RTX 20シリーズ以降、またはAMD RX 6000シリーズ以降）のほか、現在はWindowsのみをサポートしている旨が記載されています。このOSの要件としてWindowsが挙げられている点については、IVS側の推奨環境である「Windows 10 or Windows 11」という点にも一致しますね。
Multitrack Video利用の際には、Windows版の最新のOBS Studio、そしてGPUが搭載されている必要がある点を押さえておきましょう。
なお、OBS Studio以外でこのMultitrack Video機能は使用できない、といった制限はないようです。しかし、Boradcast software側でUser Guideの「Amazon IVS Multitrack Video: Broadcast Software Integration Guide」に記載がある必須機能を実装している必要があります。（なお後述しますが、Twitchの同等機能ではXSplit Broadcaster 4.5.2406.1801（以降）も動作要件に含まれています。Amazon IVSでも利用できるかもしれませんね。）
ネットワーク帯域について
Multitrack Videoを利用する際はネットワーク帯域にも注意が必要です。ABR用の各レンディションの映像をクライアント側で生成し、すべてIVS Channelにアップロードします。Multitrack Video機能を使用しない場合は最大解像度のみをアップロード、ABR用の各レンディションの映像をサーバ側で生成するわけですので、結果としてMultitrack Video機能を有効にしたほうが、無効の場合よりも多くの情報をIVS Channelに送信することとなります。
Amazon IVS Multitrack Video: Setup Guideの推奨環境では持続的に12Mbpsの帯域を挙げています。また後ほど確認しますが、マネジメントコンソール上では総ビットレート15Mbpsまでの入力を送信できると記載もあります。通常のStandard Channelでは入力最大ビットレートが8.5Mbpsであることを考えると、より大きなアップロード帯域が必要であることが実感できますね。
アップストリーム帯域幅に制限がある場合や不安定である場合などは、慎重にMultitrack Videoが利用できるかを検討しましょう。
IVS Multitrack VideoとTwitchとの関連について
先ほどOBS Studio 30.2 Release Notesを確認した際、OBS StudioのMiltitrack Video sstreamingについて、TwitchでEnhanced Broadcastingと呼ばれている旨が記載されていました。このTwitchのEnhanced Broadcastingについても確認してみましょう。記載されているリンク先は以下です。
筆者はTwitchのストリーミングまわりに明るくなかったため、こちらのドキュメントならびにTranscoding Options FAQに記載されている内容がとても参考にになりました。Twitchでストリーミングする際のABRについて、Twitch側でのトランスコードにより複数のABR用レンディションが作成されることがあるが、こちらは毎回得られるわけではない（すべてのストリーミングでABRが利用可能ではない）とのことです。ただし、Twitchのパートナーについてはこのトランスコード、高品質オプションが常に有効になり常時ABRが利用できるとのこと、そしてパートナーでない場合には、Twitch側ののリソースが利用可能な場合に限りトランスコード（ABR）を利用できるとのことです。
このようにTwitchではトランスコード、ABRの利用に制限があるのですが、Enhanced Broadcasting機能（OBS StudioとIVSでいうのMultitrack Video streaming）を使うことで、ABR用の各レンディションをBroadcast Software側で直接生成し送信することができ、パートナーでなくてもABRが常に利用できるようになる、ということです。
IVS Low-latency StreamingについてはTwitchと同じテクノロジーに基づいて構築されているということが紹介されています。（Amazon Interactive Video Service のよくある質問）機能の内容から、TwitchのEnhanced Broadcasting機能がIVS Low-Latency StreaminigでいうMultitrack Video機能であることがわかりますが、ABRストリーミングの実現について、TwitchとIVSでこのような違いがあるのは興味深いですよね。
マネジメントコンソールからMultitrack Video用IVS Channelを作成してみた
ここまでIVS User Guideや各種情報から、Multitrack Video機能についてその動作やメリット、注意事項などを確認してきました。続いては実際にMultitrack Video機能を有効にしたIVS Channelの作成までの流れを確認していきたいと思います。ライブストリーミングを行いABRラダーまで確認できればよかったのですが、今回のOBS Studio稼働の条件であるWindows環境が準備できなかったため、Channelの作成までとしています。
IVSのマネジメントコンソール、Low-latency streaminigのChannels一覧画面の(Create channel)ボタンから進みます。Channel nameを適切に入力、Channel configrationでDefault configurationを選択すると Multitrack encoding がDisabledとなってしまいますので、Cosutom configurationを選択します。またChannel typeはStandardを選択します。（Standard以外ではMultitrack encodingの項目が表示されません。）
あとはSetupの項目の最後、 Multitrack encoding のEnable multitrack inputを有効にすればよいと思いきや、もう一つ上の項目、 Container format にも注目してみましょう。デフォルトはMPEG Transport Stream (TS)ですが、Multitrack Video Input利用の際にはfMp4が必須ということで、Fragmented MP4 (fMP4)に変更しておきます。
続く Multitrack encoding の項目でEnable multitrack inputを有効にすると、 Multitrack policy と Multitrack maximum resolution という2つの設定項目が現れます。
Multitrack Policy でAllowを選択すると、クライアントがMultitrack Video機能を使うことを「許可」し、Single-track videoが送信された場合は通常のIVS Standard Channelのようにサーバ側でトランスコードするようフォールバックします。もう一つのRequireを選択すると、クライアントがMultitrack Video機能を使うことを「必須化」します。サーバ側でトランスコードするフォールバックは行われません。
Multitrack maximum resolution では、許容される最大解像度を指定します。先ほど確認した通り、Multitrack Video機能を使えば、Standard Channelと比べてLive Video Input Costは削減できます。さらにLive Video Output Costを削減したい場合、ここで最大解像度を指定することができるというわけですね。
以上でMultitrack Video機能を有効にするためのIVS Channel側の設定は完了です。(Create channel)ボタンを押下してChannelを作成しましょう。Multitrack inputを有効にして作成したChannelでは、Channel詳細画面で以下のようにMultitrack encodingがEnableであることと、Multitrack inputならびにその設定項目が表示されます。
ところで設定項目にあった Container format については、AWS API Changesの内容などから、今回のMultitrack Video機能アップデート時に新たに追加された設定と理解しています。
まとめ
Amazon IVS Low-Latency Streamingの新機能、Multitrack Videoについて、その概要やメリット、利用時の注意事項などを確認してみました。また、マネジメントコンソールからMultitrack Video機能を有効にしたChannel作成の流れを確認してみました。実際のライブストリーミングを行っての確認についても、Broadcast Software側の準備ができればやってみたいと思います。
個人的にはこのMultitrack Video機能で行われるクライアントサイド（Broadcast Software側）でのABR用のエンコード処理については、現在のサーバサイドでのABR用のトランスコードが主流になる前に使われていたもの、という印象が強いです。具体的には10年から15年ほど前の、Streaming ServerとしてAdobe Media Server主流だったころの話ですね。Adobe Media Serverのバージョンが4.0のころだったかと思います。クライアントサイドではBroadcast SoftwareとしてAdobe Flash Media Live Encoder (FMLE)を使って、マルチビットエンコーディングを行い、ABR用のすべてのレンディションをStreaminig Serverに送信していました。
当時はライブストリーミング実施の際のアップロード帯域が十分に確保できないことも多く、複数のエンコーディングのうち1つが切断、なんてこともあった記憶があります。また、当時まだWowza Streaming Engineと名乗っていたWowza Media Serverのバージョン3ごろからLive transcoding機能が使えるようになり、サーバサイドでのトランスコードが可能になりました。この機能（サーバサイドでのABR用トランスコード）のおかげで、アップロード帯域やクライアントサイド（Broadcast Software）のコンピュータリソースが節約できることを非常に便利に感じたものです。
現在では、サーバサイドでのトランスコーディングはいたって普通のものになった印象です。例えば本エントリで扱ったAmazon IVSのほかにも、AWS Elemental Media Srvicesを使ったライブ配信構成でもサーバサイドでのトランスコーディングが定番となっていますよね。そんな今、改めてクライアントサイドでのマルチビットレートエンコーディング、Multitrack Video機能が注目されていることに少し驚いたりもしています。
いずれにせよ、メリット・デメリットをしっかりと理解して適切に使用していきたい機能だなと思いました。
